When developing software, it is not uncommon for the developer, or programmer, to want to know if the software will perform as expected. More often than not, the developer wants to know if the software has any errors at various stages in the development of the software, rather than wait until the development is complete. Determining if the software contains any errors, or bugs, is referred to as debugging. Typical software development tools, such as rapid application development (RAD) tools, include the ability to debug the software under development. For example, utilizing Microsoft's VISUAL STUDIO .NET or Visual Basic .NET development tool, an application under development can be debugged by simply depressing the F5 key. Typical RAD programmers use the debugging functionality often. Many developers tend to follow the philosophy of “try it out until it works.” That is, they write a section of code and invoke the debugger. If no bugs are found, they write the next section of code. If bugs are found, they fix the code and run the debugger again. Given the frequency with which typical developers start the debugger, it is clear that a quick experience starting the debugger is very important to a developer. Also, fast debugging allows the developer to develop an application quickly, thus reducing development costs.
However, many existing software development tools take a relatively long time to get the debugger up and running after the developer commences debugging. Typically, the developer is presented with a rather long delay between invoking the “Debug” command and the time her application starts executing. In many cases, this long delay is due to the necessity to initialize the runtime environment and start the debugger.
It is clear therefore, that a desire exists for the ability to quickly debug an application after the developer starts the debugging process.